To: OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
Previously posted to the OpenDoc list:
Hi there,
I've been experimenting with an idea for designing part editors...
All of the sample code I've seen implements a style of bridge pattern where the SOM part communicates with a C++ in a bi-directional fashion. Whilst this doesn't present any big overhead, I feel that the SOM part could be used directly and that having a C++ object hanging around might therefore be unnecessary. I note that the reasons for implementing a bridge are:
- little maintenance to the IDL thus promoting efficient compilations; and
- developer's don't have to become familiar with IDL.
(I think that the second point is a non-starter given that learning SOM/CORBA IDL is a useful skill to have anyway.)
Now, making a change to the interface e.g. introducing a new method requires changing the IDL right? Nope. This, I suspect, has been the driving force behind creating the C++ bridge. However, by use of the "passthru" directive in the "implementation" section of an IDL file, a developer can declare code that will be included directly in the emitted files of their choice. I declared the following line in my IDL:
passthru C_xih_after = "#include \"MyPart.h\"";
the above statement informs my IDL compiler to include the "#include \"MyPart.h\"" immediately after all other includes in my .xih file (SOM C++ implementation header file). The \" is simply escaping the quotes so that the line is reproduced properly in the emitted file.
MyPart.h defines a specialisation of my SOM part (which, of course, is a specialisation of ODPart) but declares private and protected characteristics only. Changes to MyPart.h do not require any IDL re-generation and I have only the one C++ object.
That's basically the crux of it. Thoughts/ideas/suggestions please.
(It'd be neat to get a sample part code from Apple along these lines presuming that the idea's a good one).
